Atomic State Management
#状態管理(GUI) #設計 #宣言的UIの設計レシピ
Recoil, Jotai, Riverpodのようなボトムアップ型の状態管理(GUI)アプローチを指す
Opticsや遅延束縛など、関数型プログラミングに多大な影響を受けている
Atomic State Managementのパラダイム
ObservableとSelectorとStreamを扱いやすくしたようなようなモノ
Shallow Moduleの集まり
これ自体がフレームワークやアーキテクチャになることはない
分散型と言われるが、中のデータは分割統治されている
RecoilでいうRegistry
JotaiでいうWeakMap
他ライブラリとの類似性
Rx
Atomic State Management(Recoil, Jotai)とRxの共通項
Redux
/study-react/Recoil が面白いので Redux との違いを説明してみる
Recoil のアプローチを一言でいうなら、アプリケーションの状態を有向グラフで表現するということ
/mrsekut-p/分散系state LibraryでModelingする
RecoilとJotaiの比較
https://blog.logrocket.com/jotai-vs-recoil-what-are-the-differences/
Recoilのモチベーション
https://recoiljs.org/docs/introduction/motivation/
Recoilのパターンと良いところ
Atomic State Managementの哲学や導入するモチベーションを改めて整理する
トップダウン型と比較すると差分レンダリングの調整が容易
Reduxはディスパッチの度にすべてのミドルウェアを実行し、すべてのコンポーネントに対してループしてmapsStateToPropsを実行する
^ Data-Flow Graphの場合はグラフ構造でボトムアップに差分検知するため、そのような挙動がない
Recoilはグローバル状態管理ライブラリなのか
Recoilはshared state、つまり共有状態管理ライブラリと呼ぶ方が適切かもしれません。
#Module_Level_State
パッケージング
unopinionatedでどう使うかは利用者に委ねられる
これがお気に入りkoushisa.iconkoushisa.icon*2
コードスニペットはインターネットに溢れているのに対しコードベースはすべてユニーク
SVO型のパッケージングで機能的凝集を目指すオニオンアーキテクチャ
Warning: Recoil doesn't scale well with larger and more complicated apps
easyではなく、simple寄りなので一定の経験は必要
上記のissueは利用ケースが合っていなかったために苦労した談だと思われる
koushisa.iconはこのような問題を解決したことがない
Race Conditionやデータフロー迷子については実装をRecoilに寄せ過ぎな気がする
モデリングに問題がある: ドメインと問題空間と解決空間
仮にディレクトリ名が atoms, selectors だった場合、そのアプリケーションは React と Recoil を使った何かにしか見えない
@t6adev: これを見て自分の中の靄が晴れてきた感じ。
Jotai / Recoil は従来のReduxのようなトップダウンな状態管理ライブラリではなくボトムアップ型。
なので一元的にまとめるような構成は哲学に反してる気がする。
Single source of truth 、巨大なstoreから切り出すのを忘れよう？
https://zenn.dev/8_8/articles/58d2caa3cc4fa5
ステート管理を超えるRecoil運用の考え方
Recoilを他のライブラリと組み合わせる可能性
ライブラリ間とのコミュニケーションとしての役割
State managementからData-flow graphへ
Recoil/Jotai使う前にトップダウン型の状態管理をアンラーニングすべし
コンポーネントツリー
宣言的UIのモジュラリティや堅牢性はコンポーネント設計で担保する
koushisa.icon
状態管理(GUI)#641ce53d8660300000a8f8df
atomWithAspida
jotai-molecules
jotai-tanstack-query